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(57) ABSTRACT 

A technique identifies a data session flowing through entities 
ofij^multi-protocol network based on information contained 
v5ttB^0 a service request provided by a user of the network 
and' without requiring knowledge of the protocols used by 
the session. A translation server translates the service request 
into session parameters for use by a correlation engine. The 
correlation engine creates at least one filter containing 
searching criteria pertaining to the session and passes the 
filter to at least one protocol server configured to obtain 
specific protocol-related information pertaining to the ses- 
sion. The protocol server searches a repository for informa- 
tion matching the filter and, if found, returns a list of 
sessions. 
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METHOD AND APPARATUS FOR 
DETERMINING SNA SESSIONS USING 
VARIOUS PROTOCOLS FOR TRANSPORT 
BASED ON FILTER CRITERIA 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The present invention is related to the following copend- 
ing and commonly asigned U.S. Patent Applications: 

U.S. patent application Ser. No. 08/999,271 titled, Tech- 
nique for Correlating Logical Names with IP Addresses on 
Internetworldng Platforms, by Wayne Clark et al., filed on 
Dec. 29, 1997; 

U.S. patent application Ser. No. 09/315,550 titled, 
Method and Apparatus for SNA/IP Correlation with Mul- 
tiple DLSw Peer Connections, by Darin Ferguson et al., filed 
herewith; 

U.S. patent application Ser. No. 09/315,551 titled, 
Method and Apparatus for SNA/IP Correlation in a Mixed 
APPN and DLSw Network, by Darin Ferguson et al., filed 
herewith; 

U.S. patent application Ser. No. 09/315,443 titled. 
Method and Apparatus for Determining a Path for a Session 
Using Various Protocols for Transport, by Darin Ferguson et 
al, filed herewith; and 

U.S. patent application Ser. No. 09/315,284 titled. 
Method and Apparatus for Establishing a Database Used for 
Correlating Information Gathered via SNMP, by Darin Fer- 
guson et al., filed herewith, each application of which is 
hereby incorporated by reference as though fully set forth 
herein, 

HELD OF THE INVENTION 

The present invention relates to computer networks and, 
more particularly, to management of entities in a multi- 
protocol computer network. 

BACKGROUND OF THE INVENTION 

Data communications in a computer network involves the 
exchange of data between two or more entities intercon- 
nected by communication links and subnetworks. These 
networks are typically software programs executing on 
hardware computer platforms which, depending on their 
roles within a network, may serve as host stations, end 
stations or intermediate stations. Examples of intermediate 
stations include routers, bridges and switches that intercon- 
nect communication links in subnetworks; an end station 
may be a computer located on one of the subnetworks. More 
generally, an end station connotes a source of or target for 
data that typically does not provide routing or other services 
to other computers on the network. A local area network 
(LAN) is an example of a subnetwork that provides rela- 
tively short -distance communication among the inter- 
connected stations; in contrast, a wide area network (WAN) 
facilitates long-distance communication over links provided 
by public or private telecommunications facilities. 

End stations typically communicate by exchanging dis- 
crete packets or frames of data according to predefined 
protocols. In this context, a protocol represents a set of rules 
defining how the stations interact with each other to transfer 
data. Such interaction is simple within a LAN, since these 
are typically "multicast" networks: when a source station 
transmits a frame over the LAN, it reaches all stations on 
that LAN. If the intended recipient of the frame is connected 
to another LAN, the frame is passed over a routing device 
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to that other LAN. Collectively, these hardware and software 
components comprise a communications network and their 
interconnections are defined by an underlying architecture. 
Most computer network architectures are organized as a 

5 series of hardware and software levels or "layers" within 
each station. These layers interact to format data for transfer 
between, e.g., a source station and a destination station 
communicating over the network. Specifically, predeter- 
mined services are performed on that data as it passed 

iQ through each layer, and the layers communicate with each 
other by means of the pre-defined protocols. This design 
permits each layer to offer selected services to other layers 
using a standardized interface that shields the other layers 
from details of actual implementation of the services. The 

J 5 lower layers of these architectures are generally standard- 
ized and implemented in hardware and firmware, whereas 
the higher layers are usually implemented in the form of 
software. Examples of such communications architectures 
include the System Network Architecture (SNA) developed 

20 by International Business Machines (IBM) Corporation and 
the Internet Communications Architecture. 

The Internet architecture is represented by four layers 
termed, in ascending interfacing order, the network 
interface, internetwork, transport and application layers. The 

25 primary internetwork layer protocol of the Internet archi- 
tecture is the Internet Protocol (IP). IP is primarily a con- 
nectionless protocol that provides for internetworking 
routing, fragmentation and reassembly of exchanged 
packets — generally referred to as "datagrams" in an Internet 

30 environment — and which relies on transport protocols for 
end-to-end reliability. An example of such a transport pro- 
tocol is the Transmission Control Protocol (TCP), which is 
implemented by the transport layer and provides connection- 
oriented services to the upper layer protocols of the Internet 

35 architecture. The term TCP/IP is commonly used to denote 
this architecture; the TCP/IP architecture is discussed in 
Computer Networks, 'Srd edition^ by Andrew S. Tanenbaum, 
published by Prentice-Hall, PTR in 1996, all disclosures of 
which are incorporated herein by reference, particularly at 

40 pages 28-54. 

SNA is a communications framework widely used to 
define network functions and establish standards for 
enabling different models of IBM computers to exchange 
and process data. SNA is essentially a design philosophy that 

45 separates network communications into several layers 
termed, in ascending order, the physical control, the data link 
control, the path control, the transmission control, the data 
flow control, the presentation services and the transaction 
services layers. Each of these layers represents a graduated 

50 level of function moving upward from physical connections 
to application software. 

In the SNA architecture, the data link control layer is 
responsible for transmission of data from one end station to 
another. Bridges or devices in the data link control layer that 

55 are used to connect two or more LANs so that end stations 
on either LAN are allowed to access resources on the LANs. 
Connection-oriented services at the data link layer generally 
involve three distinct phases: connection establishment, data 
transfer and connection termination. During connection 

60 establishment, a single path or connection, e.g., an IEEE 
802.2 logical link control type 2 (LLC2) or "data link 
control" connection, is established between the source and 
destination stations. Once the connection has been 
established, data is transferred sequentially over the path 

65 and, when the LLC2 connection is no longer needed, the 
path is terminated. Reliable communication of the LLC2 
(DLC) is well known and described by Andrew Tanenbaum 
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in his book Computer Networks, Second Edition, published 
in 1988, all disclosures of which are incoq^o rated herein by 
reference, especially at pages 253-257. 

HG. 1 is a schematic block diagram of a conventional 
computer network 100 having a host computer coupled to a 
Token Ring (TR) network TRl and an end station coupled 
to TR2. The TR networks are of the type that support 
Source/Route Bridging (SRB) operations with respect to the 
contents of a routing information field (RIF) of a frame. The 
host computer is preferably a SNA host entity comprising a 
host mainframe computer 110 coupled to a channel-attached 
router or a front end processor (FEP), such as an IBM 3745 
network control processor, hereinafter referred to as the 
"host network connection" 112. In addition^ the end sta tion 
is an SNA entity 114 comprising a ^physical unit" (PU^ and 
a ''logical unit" (LU) which consists of logical services by 
which a user may access the SNA network. A control unit 
106 (such as IBM 3174) interconnects TRl and TR2 such 
that the SRB network 100 effectively functions as a LAN. 
SNA protocols, such as a hierarchical sub-area SNA proto- 
col that defines a connection path between the PU and host, 
are used throughout the network. 

In an alternate embodiment of network 100, Remote 
Source Route Bridging (RSRB) routers 1,2 operate in con- 
junction with the host network connection 112 to provide IP 
connectivity over a TCP/IP cloud 110 with the SNA network 
100. RSRB is a software component in each router that 
permits transmission of TR frame trafi5c across an IP net- 
work. Specifically, RSRB functions to give the IP network 
the appearance of a single, virtual token ring (VTR) "hop" 
in a TR network. The association of the two adjacent RSRB 
routers is called a "peer" relation and this relation must exist 
to exchange RSRB traffic across the VTR. 

The PU entity communicates with the host by exchanging 
TR frames over LLC2 connections or sessions through the 
SRB network. Each TR frame 120 includes a RIF 122 that 
contains source route information in the form of ring 
number/bridge number pair "hops" within a path between 
the stations. An LLC2 session is established between the 
stations using a special TR frame, called an explorer frame. 
The explorer frame is used by a source (PU) to "discover" 
the path to a destination (host); thereafter, a Set Asynchro- 
nous Balanced Mode Extended (SABME) frame is sent from 
the PU to the host to establish a logical connection between 
the end stations, and the host responds to the SABME frame 
with an Unnumbered Acknowledgment (UA) frame. Once 
the UA frame is received by the PU, a connection is 
established between the source and destination, and these 
stations communicate by exchanging TR information 
(INFO) and acknowledgment frames until the logical link 
SNA session is completed. 

For example, the PU transmits an INFO frame over TR2 
and through the control unit and TRl to the host. Upon 
successfully receiving the INFO frame, the host responds by 
transmitting an LLC2 Receive/Ready (RR) acknowledg- 
ment frame over the SRB network to the PU. This INFO/RR 
exchange continues until the PU has successfully transmit- 
ted all of its data and the host has successfully received all 
of that data. Session completion is then initiated by a 
Disconnected Mode (DM) frame being transmitted from the 
PU to the host; the disconnection is thereafter acknowledged 
by the host responding with a UA frame. The LLC2 frames 
(packets) are described by Radia Perlman in her book 
Interconnections, Bridges and Routers, published by Addi- 
son Wellesly Publishing Company, in 1992, all disclosures 
in which are incorporated herein by reference, particularly at 
pages 33-34. 
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In a SNA network, applications executing on end stations 
typically access the network through LUs of the stations; 
accordingly, in a typical SNA network, a communication 
session may connect two LUs in a LU-LU session. 

5 Advanced Peer to Peer Networking (APPN) functions gen- 
erally include session establishment and session routing 
within an APPN network. FIG. 2 is a schematic block 
diagram of an APPN network 200 comprising a host 202 
coupled to a host network connection entity 206 and a PU 
entity 212 coupled to token ring (TR) LAN TRl. During 
session establishment, an end station (such as PU 212) 
requests an optimum route for a session between two LUs; 
this route is calculated and conveyed to PU 212 by an 
intermediate station (e.g., station 216) via a LOCATE mes- 
sage exchange through the network 200. Thereafter, a "set- 
up" or BIND message is forwarded over the route to initiate 
the session. The BIND includes information pertaining to 
the partner LU requested for the session. 
Intermediate session routing occurs when the intermedi- 

2Q ate station 216, configured as an APPN network node (NN), 
is present in a session between the two end nodes. As can be 
seen, the APPN network node is connected to an APPN/ 
WAN 210 that includes additional APPN NNs to extend the 
APPN architecture throughout the network. The APPN 

25 network nodes forward packets of a LU-LU session over the 
calculated route between the two APPN end nodes. An 
APPN network node is a fill-functioning APPN router node 
having all APPN base service capabilities, including session 
services functions. An APPN end node, on the other hand, is 

3Q capable of performing only a subset of the functions pro- 
vided by an APPN network node. APPN network and end 
nodes are well-known and are, for example, described in 
detail in Systems Network Architecture Advanced Peer to 
Peer Networking Architecture Reference IBM Doc 

35 SC30-3422 and APPN Networks by Jesper Nilausen, printed 
by John Wiley and Sons, 1994, at pgs 1^3. 

The APPN router node may provide Dependent LU 
Requester (DLUR) services on behalf of the PU 
("dependent" LU) in network 200 while a virtual telccom- 

40 munication access method (VTAM) on the host 202 may 
provide Dependent LU Server (DLUS) services. The DLUS 
host may be coupled to the DLUR router by way of a "pipe" 
connection over which control traffic for the dependent 
session flows. The DLUR router essentially functions as a 

45 "surrogate" for the downstream PU with respect to the 
DLUS host such that the control information flows over the 
network to the PU by way of the DLUR router. 

Data Link Switching (DLSw) is a mechanism for for- 
warding SNA protocol frames over, e.g., a TCP/IP backbone 

50 WAN such as the Internet. In traditional bridging, the data 
link connection is end-to-end, i.e., effectively continuous 
between communicating end stations. A stream of data 
frames originating from a source station on a source LAN 
traverses one or more bridges specified in the path over the 

55 LLC2 (DLC) connection to a destination station on a des- 
tination LAN. In a network implementing DLSw, by 
contrast, the LLC2 connection terminates at a local DLSw 
device entity, e.g., a router. An example of a DLSw network 
arrangement may comprise a host DLSw router connected to 

60 a host computer via a host LAN and a remote DLSw router 
connected to a remote LAN having a destination station. The 
LANs that are accessed through the DLSw routers may 
appear as SRB subnetworks attached to adjacent rings; each 
of these adjacent rings manifest as a virtual ring within each 

65 DLSw router that effectively terminates the SRB network. 
A DLSw network is formed when two DLSw devices 
interconnect the end nodes of a SNA network by way of the 
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IP network; the DLSw devices preferably communicate that identifies the LLC2 circuit within a DLSw circuit. The 

using a Switch-to-Switch protocol (SSP) that provides DLSw circuit ID generally comprises a data link circuit port 

packet "bridging" operations at the LLC (i.e., DLC) protocol ID (4 bytes) and a data link correlator (4 bytes). A pair of 

layer. FIG. 3 is a schematic block diagram of a DLSw circuit IDs along with a data link ID uniquely identifies a 
network 300 having a TCP/IP cloud 310 disposed between 5 single end-to-end circuit through the network. Notably, each 

host and remote SRB subnetworks 320, 330. Each SRB DLSw router maintains a table 350 comprising a plurality of 

subnetwork comprises a DLSw router 1, 2 coupled to a data link ID and corresponding DLSw circuit ID pair entries, 

host/host is network connection 302, 304 and PU/LU 312 associate LLC2 frame trafSc with a correspond- 

via TRl and 2, respectively. The DLSw routers function as ^^"^ ^^^^ communicatmg over the IP cloud, 

end points between TCP sessions over the TCP/IP cloud lO ^^""^ 'yP^cally mdexes mto the table (the 

when transporting TR frames associated with DLC sessions "^^^ *^^*^") ^^"S ^ ^^^^ ^'"^ ^ *° 'he corresponding 

over that intermediate network. In an alternate embodiment DLSw circuit IDs. 

of network 300, RSRB routers 1, 2 may be substituted for ^ ^ schematic block diagram of a conventional 

DLSw routers 1 2. network 400 wherein a host mainframe 402 is coupled to a 

D ji . . J u FM c * ♦ ur u a K Telnet 3270 server 404, which preferably executes on a 

Broadly stated, each DLSw router establishes a "peer , , ^ . ^i^-^nr^ . • 

1 *• u- "* *u rue * ■ J channel-attached router The TN3270 router IS coupled to an 

relationship to the other DLSw router m accordance with a , ... TY-n/m i j n ^ 

conventional capabilities exchange message sequence, and 'f, ''''}°" JS^^^ f 

the logical and physical connections between these routers *"?P'T T^^"^ °' '° '''^^^'^ 'uT 

connect the subneiworks into a larger DLSw network. To ^^^^T" T J^^^f " '^e 
,.1.. ... J • 1 in TN3270 router. Tlie Telnet connection IS well known to the 

establish a peer connection in accordance with an imple- 20 -u ^ • n/-^ or>< o^.^ 

r c u* *u u . T^r c . c . Internet community and described in RFCs 854, 860 and 
mentation of DLSw switching, the host DLSw router first 

opens logical TCP (Read/Write) "pipe" connections to the „' . , . , . 

remote DLSw router using a conventional socket technique managing a mulu-protocol TCP/IP-based SNA 

to create a socket into the transport layer of the protocol ^^^^^.^ protocols used for carrymg the SNA 
stack. Once the TCP pipes are established, the SSP protocol 25 sessions along with informaUon pertaming to the protocols, 

is used to transport the capabiUties exchange messages ^""^^^ '.^ diagnose points of failure for 

between the two DLSw routers. ^^^^^^ behaving improperly or to determine the 

^ . , . . sessions that may be affected when performing maintenance 

The capability exchange messages contam various „^ ^^,^^3 ^ ^^ ^ q^S^ 

parameters, such as the number of pipes used for commu- ^^out the DLSw protocols used to transport SNA 

mcalmg between the DLSw routere and the largest frame ^^^^^^ i3 ^^^j,^,,,^ ,^ ^ ^^^^^ ^ ^^^^^^ ^ 

size supported by the routers. Each DLSw router responds to management station (NMS) 380 via a Simple Network 

each capability exchange message issued by its peer router Management Protocol (SNMP). The DLSw circuit informa- 

with a capability exchange response message. Upon comple- described above, including the data link IDs, are avail- 

tion of the exchange, each router reconfigures .tself to act ^f,,^ ^^^^ 380 by accessing DLSw management 

"''°u,- 'he agreed capabihti^ and the peer connection is ^formation base (MIB) tables within the routers using 

established Establishment 0 a peer connection can occur gNMP. The MIB and SNMP protocol, and their use in 

automatically upon boot-up of each DLSw router; that is. ^viding network management information between 

as soon as a DLSw router activates, it connects with its g^MP management stations and agents are well-known and 

P peer. TTie DLSw forwarding mechanism is well described in, e.g., SiVM/^ SJ^Affv2 and ^OAT by William 

riSp^ 170. f 'w n I" R ,t i"ao-fr" ^"^f"'"'"""' Stallings. printed by Addison Wesley Publishing Company, 

(RFC) 1795 by Wells & Bartky, 1995 at pgs 1-91. ^^g^ 

DL^w routers can establish multiple parallel TCP ses- ^ ^^^^^^ involving a PU session in the network 300 may 

sions usmg well-known port numbers. All frames associated 5^ diagnosed by the network operator using a conventional 

with a particular LLC2 connection typically follow a single approach that correlates SNA frame traffic sessions to DLSw 

designated TCP session. Accordingly, SNA data frames j^uiers for a network having a peer connection over an IP 

onginating at the PU are transmitted over a particular LLC2 ^loud between DLSw peer routers. Typically, management 

connection along TR2 to DLSw2, where they are encapsu- t^e SNA entities takes place on the host in accordance 

lated within a designated TCP session and transported over ^jth a network management application program, such as 

the TCP/IP cloud 310. The encapsulated messages are NetView, executing on the host. The application can access 

received by DLSwl, decapsulated to their original frames ^^^^^^ ^he PU entity by virtue of its definition 

and transmitted over a corresponding LLC2 connection of contained in a specialized data structure 390 of the host 

TRI to the host in the order received by DLSw2 from the PU. ^^^^^^^^ connection. This data structure is a VTAM table 

The LLC2 connection between the PU and host is idcn- 3SW) having entries whose contents define all the PUs with 
tified by a data link identifier (ID) 360 consisting of a pair 55 respect to the host. The content definitions of the entries 

of attachment addresses associated with each end station. comprise a name (e.g. PU name 392) along with an identifier 

Each attachment address is represented by the concatenation block number/identifier number (IDBLK/IDNUM 394) or 

of a media access control (MAC) address (6 bytes) and a control point (CP) name that uniquely identifies each PU on 

LLC service access point (SAP) address (1 byte). a network at a given time. 

Specifically, each attachment address is classified as either a 50 The NetView application manages those SNA resources 

target address comprising a destination MAC (DMAC) and known to it; as used in this context, the term "managing" 

a destination SAP (DSAP), or an origin address comprising means that the application program can check and change 

a source MAC (SMAC) and source SAP (SSAP) addresses. the status of the resources, and can further control those 

The attachment addresses are contained in the TRs frame resources to acquire, e.g., information leading to the trafiSc 
exchanged between the PU and host entities, 55 patterns of the resources. However, the NetView application 

Furthermore, the designated TCP session is identified by cannot manage the component in the routers that encapsulate 

a pair of circuit IDs 370, each comprising a 64-bit number SNA traffic. As noted, the DLSw routers are preferably 
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managed by ihe SNMP tool executing on the NMS which 
communicates with SNMP agents resident on the routers. 

According to the conventional approach, the NMS com- 
municates with an SNMP agent in each DLSw router to 
acquire DLSw MIB information including a data link ID 
identifying a DLSw circuit associated with the router. Since 
the host computer "owns" SNA sessions in the network, it 
maintains SNA-specific information (in addition to the PU 
name) such as the MAC/SAP addresses 396 for the host 
network connection and the PU on VTAM 390 in the host. 
A SNA View application is also resident on the host and used 
to acquire the MAC/SAP addresses and PU names. SNA 
View also communicates with VTAM to collect static defi- 
nition information associated with the PU name if the PU is 
statically defined. 

A complementary version of SNA View (i.e., CiscoWorks 
Blue SNA View) executes on the NMS and communicates 
with the host application over a logical TCP/IP (or LU 6.2) 
"pipe" connection 385. The SNA View application on the 
NMS obtains the SNA-specific information from VTAM 
390 over the pipe 385 and stores that information on a 
storage repository, such as a NMS database 382, of the 
NMS. In the case of DLSw network 300, the SNA-specific 
information retrieved from VTAM does not include infor- 
mation with respect to the DLSw routers that are routing the 
session trafiBc. Using the PU name of a session, an SNMP 
manager on the NMS may then correlate local and remote 
MAC/SAP addresses to the PU name in accordance with a 
conventional correlation procedure. Thereafter, the NMS 
can draw the topology of the DLSw network, including the 
DLSw circuit and PU session, to isolate any failures in the 
network. 

Atypical problem that arises with each of the networks of 
FIGS. 1-4 is that a customer cannot connect an end station 
into the network. As a result, the customer calls a network 
operater which uses conventional tools (such as CiscoWorks 
Blue SNA View and various CiscoWorks Blue Maps 
products) to diagnose the problem in the particular network. 
For example, the SNA View tool may be used to diagnose 
network 100 (FIG. 1), an APPN Maps application tool may 
be used to diagnose network 200 (FIG. 2), DLSw Maps and 
RSRB Maps application tools may be used for the configu- 
rations of FIG. 3, and a TN3270 monitor application may be 
used to diagnose network 400 (FIG. 4). The TN3270 moni- 
tor provides a list of PU sessions and status within a TN3270 
network. 

Utilizing these conventional tools, the NMS may display 
sessions of a particular protocol and perform a certain level 
of "fihering" (i.e., searching) within the protocol. For 
example if the customer provides the name of the end station 
(PU) that cannot connect into the network, then the operator 
may invoke the SNA View tool to search for sessions based 
on that PU name because SNA trafBc applies across all of the 
network configurations of FIGS. 1-4. The NMS may thus 
filter and display, e.g., all physical unit (PU) sessions known 
to VTAM and all VTAM PU sessions having names starting 
with a particular character sequence. SNA View would also 
enable display of the active/inactive status and other relevant 
information pertaining to the session. 

To obtain further information, the operator investigates 
use of all available protocol tools, particularly if the cus- 
tomer has no detailed knowledge of its installed network. 
For example, the operator may invoke the APPN Maps and 
DLSw Maps tools to determine whether they have any 
knowledge of the particular PU session. The DLSw Maps 
tool includes a display screen that allows input of filtering 
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criteria, such as a PU name. In response to the criteria, the 
tool provides a list of DLSw circuits that represent (carry) 
PU sessions and that meet the particular filter criteria. The 
circuit information includes local and remote MAC/SAP 

5 addresses of the circuits. The CiscoWorks SNA View prod- 
uct enables access to the VTAM information in the host to 
allow correlation between the DLSw circuit information and 
the PU names from VTAM using the MAC/SAP addresses. 
However, these conventional tools cannot provide a list of 

10 circuits (sessions) based on filter criteria without specifying 
the protocol. 

Thus, it would be desirable to show all sessions in a 
network, regardless of protocol, that have a particular filter 
criteria, such as a PU name, MAC/SAP address or IP address 

15 of the PU. The present invention is directed to a technique 
for obtaining SNA PU session information pertaining to the 
filter criteria. In addition, the invention is generally directed 
to discovering the type of protocols used in network at a 
customer site without having to rely on the customer for 

20 specific information. In particular, the invention is directed 
to a technique for identifying a session in a customer's 
network without knowledge of the protocols being 
employed. 

25 SUMMARY OF THE INVENTION 

The present invention comprises a technique for identi- 
fying a data session flowing through entities of a multi- 
protocol network based on information contained within a 
service request provided by a user of the network and 
without requiring knowledge of the protocols used by the 
session. The entities comprise a System Network Architec- 
ture (SNA) host mainframe ("host"), an end station and 
intermediate stations, such as routers. Information about the 

35 protocols used in the network is initially acquired by a 
network management station (NMS) coupled to the network. 
In the case of an SNA data session, information about the 
session is acquired from a virtual telecommunications access 
method (VTAM) table on the host and from management 
information bases (MIBs) provided by routers executing 
protocols utilized by the SNA session. 

The NMS comprises a translation server configured to 
translate the service requests into session parameters for use 
by a novel correlation engine. The NMS further comprises 

45 an application protocol server including a plurality of pro- 
tocol servers, each of which is configured to obtain specific 
protocol-related information pertaining to the session. In the 
illustrative embodiment, the protocol servers include a 
VTAM protocol server, a Data Link Switching (DLSw) 

50 protocol server, a Remote Source Route Bridging (RSRB) 
protocol server, a Telnet (TT^3270) protocol server and an 
Advanced Peer to Peer Networking (APPN) protocol server. 
Information used by the application protocol server is stored 
on a NMS repository that is preferably organized as a 

55 plurahty of tables, each containing protocol -related infor- 
mation associated with a protocol server. 

In response to receiving the session parameters from the 
translation server, the correlation engine creates at least one 
filter containing searching criteria pertaining to session. For 

60 an SNA session, the criteria may comprise one or more of 
the following elements: Logical Unit (LU) name, LU status, 
Physical Unit (PU) name, PU status, PU type, is identifier 
block number/identifier number (IDBLK/IDNUM), media 
access control (MAC) address (with or without service 

65 access point (SAP) address), Control Point (CP) name, 
Dependent Logical Unit Requester (DLUR) name, Depen- 
dent Logical Unit Server (DLUS) name, DLUS status, end 
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Station (workstation) TCP/IP host name or address (with or FIG. 4 is a schematic block diagram of a conventional 

without port number), router TCP/IP host name or address TN3270 network 400; 

and the desired protocols. The correlation engine passes the piG. 5 is a schematic block diagram of a multi-protocol 

filter to an appropnate protocol server to search its table of ^^twork comprising a plurality of stations, including a 

the repository (or its respective MI B) for information rel- 5 network management station (NMS). interconnected by a 

evant to the request^ If found, the protocol server returns a ^^^^^^^ environment on which the present invention may 

hst^of sessions (and associated information) matching the advantageously operate; 

According to the inventive technique, the initial Ust of FIG. 6 is a schematic block diagram of the NMS of FIG. 

sessions returned by a pratocol server becomes the working ^ ,^'"P"^^"S ^ correlation engine coupled to a plu- 

list. Subsequent session lists returned by the protocol servers ''^''y P^^^°^* ^^^^^ accordance with the invention; 

are merged with the working list. That is if a subsequent ^ flowchart illustratmg the sequence of steps 

session list includes information that matches information involved in a novel session list technique of the present 

about a session in the working list, then the two sessions are invention; and 

considered the same and the session information from each 15 FIG. 8 is a table diagram of a list of sessions sorted in 

protocol is combined into a single session. If the subsequent accordance with the technique of FIG. 7, 

session list information does not match the information DETAILED DESCRIPTION OF AN 

pertaining to any working list session, then the subsequent ILLUSTRATIVE EMBODIMENT 
session list information is added to the working list as a new 

session. Partial matching of the session list generally indi- 20 FIG. 5 is a schematic block diagram of a multi-protocol 

cates that the sessions are not identical; therefore an addi- network 500 comprising a pluraUty of stations embodied as 

tional multiple criteria matching operation is performed to internetworking computer platforms interconnected by a 

determine whether the sessions are similar. As each session network environment 550 of communication links and sub- 

is merged into the working list, flags are asserted to indicate networks. The stations preferably comprise a host computer 

which protocols have information about the session and 25 station 512, a network management station 

which filters were satisfied by session returned by the (NMS) 600 and a plurality of intermediate stations, the latter 

protocol server. being dispersed within the environment 550. The commu- 

A next stage of the technique involves sorting of the nication links and subnetworks contained within network 

working list session entries based on whether the sessions environment 550 may be configured as wide area networks 

match all of the filters (the highest order) and by PU name, 30 (WANs), such as a Transmission Control Protocol/Internet 

if present. Each session of the working list that matches all P^^^'ocol (TCP/IP) network, and local area networks (LANs) 

of the filter criteria is flagged as matching the requested that support source-route bridging (SRB) operations with 

filters. The session that matches all of the filters supplied to respect to the contents of a routing information field (RIP) 

aU of the protocol servers is first in the list. If there are ^ frame. 

multiple sessions that meet the filter criteria, those sessions 35 'Fhe present invention described herein generally applies 

are further sorted by PU name. Thereafter, sessions are to any type of connection -oriented, multi-protocol network 

sorted by the highest number of partially matched filtering environment 550 wherein the particular intermediate sta- 

criteria. The resulting sessions are reUirned to the user, tions carrying data traffic employ protocols that are 

preferably in a session table foniiat. unknown to a user of the network or an operator of the NMS 

Advantageously, the invention provides an interface for a 40 I" ^® illustrative embodiment, the invention may be 

network operator of a NMS to locate any managed session directed to a routed network environment that carries Sys- 

in its network by entering whatever data it knows about the terns Network Architecture (SNA) session traffic via com- 

session. The correlation engine responds by returning a list munications equipment, such as control units and/or com- 

of sessions sorted by the number of matches. By returning munication controllers (FIG. 1) or Advanced Peer to Peer 

aU sessions that match any filter criteria instead of just those 45 Networking (APPN) network nodes (FIG. 2). Moreover, the 

sessions that match all of the criteria, the inventive technique invention may be illustratively directed to a routed environ- 

avoids issues created when the operator mistakenly enters naent 550 that carries encapsulated SNA session traffic over 

conflicting information. Moreover, the inventive technique a TCP/IP network using intenmediate stations (e.g., routers) 

enables the correlation engine to choose a session from tbat employ protocols such as Data Link Switching (DLSw, 

potentially many sessions as a correct session for the filter- 50 FIG. 3), Remote Source Route Bridging (RSRB, see 

ing criteria. FIGS. 1 and 3) or Telnet (TN3270, see FIG. 4). 

RRTPP nF^iCRIPTtOM OF THF DRAWINGS ^^^^ computer ("host") 510 is preferably a SNA host 

BRIEF DESCRIPTION OF THE DRAWINGS ^^^.^^ ^^p^sing a mainframe computer coupled to either a 

The above and further advantages of the invention may be channel-attached router, a front end processor or an APPN 

better understood by referring to the following description in 55 network node. The end station 512 is also a SNA entity that 

conjunction with the accompanying drawings in which like may comprise an APPN end node or a Physical Unit (PU) 

reference numbers indicate identical or functionally similar functioning in accordance with APPN Dependent Logical 

elements: Unit Requestor (DLUR) services. In the latter case, the 

FIG. 1 is a schematic block diagram of a conventional APPN network node (i.e., router) preferably incorporates the 

computer network having a host computer and end station go DLUR function, while the host 510 incorporates a Depen- 

coupled to a plurality of token ring local area networks to dent LU Server (DLUS) function. 

form a source-route bridge (SRB) network; Each station typically comprises a plurality of intercon- 

FIG. 2 is a schematic block diagram of a conventional nected elements, such as a processor, a memory and an 

Advanced Peer to Peer Networking (APPN) network includ- input/output (I/O) unit. The memory may comprise storage 

ing APPN nodes; 65 locations addressable by the processor and I/O unit for 

FIG. 3 is a schematic block diagram of a conventional storing software programs and data structures associated 

data link switching (DLSW) network; with the inventive session list technique. The processor may 
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comprise processing elements or logic for executing the In the illustrative embodiment described herein, however, 

software programs and manipulating the data structures. An the servers reside an the same platform as the NMS. The 

operating system, portions of which are typically resident in servers may be invoked via direct method calls from the 

memory and executed by the processor, functionally orga- correlation engine 620 using defined applications program- 
nizes the station by, inter alia, invoking network operations 5 ming interfaces (APIs). 

in support of software processes executing on the station. It Information used by the protocol servers is stored on a 

will be apparent to those skilled in the art that other NMS repository 630 that may be distributed and imple- 

processor and memory means, including various computer mented as an SQL-based server comprising a database of 

readable media, may be used for storing and executing one or more disks and a cache memory. Because the 

program instructions pertaining to the technique described information may not be centrally located, searching may be 

herein, distributed among various locations in the network as 

The I/O unit, in turn, connects the station to mass storage opposed to a single location; accordingly, the invention 

devices, such as disks, and to the network environment. The contemplates the use of independent protocol servers. The 

NMS may further include a conventional display monitor repository may be further organized in a variety of manners 

with a display screen and cursor control devices, such as a including as tables (data structures) 632-^40, each contain- 
keyboard, connected to I/O unit. A window environment, information associated with a protocol 

such as a graphical user interface (GUI), is preferably '^A^ I n? c 'f^'P/^' information relevant to the 

displayed on the screen as a graphical display to facilitate ™ ^^.^ P/ur^i^^'^T^^^ "u^. ""'^-^ 

. . . . . 1 . * stored on respective tables 632 and 634, whi e information 

mteracaons between a network operator and the station. For ^^ RgRB. TN3270 and APPN protocol servers 

ine INM5,, tde aisK may tunction as a repository tor storing go5_gjo ^^ ^^^^^ 

on respective tables 636-640. 

network information as described further herein. Typically, -to, r-- w? ^ m oxrA * 1 l ■ r 

. • f . . 1 I nc Cisco Works Blue SNA View tool has a mainframe 

the I/O una receives information, such as control, addre^ component and a UNIX workstation component that allows 

and data signals, trom the keylward or the repository, and ^^^^ to retrieve SNA-specific information about the 

provides that mformaUon to the processor for display on the ^osl and PU entities. The NMS 600 communicates with the 

screen or for transfer over the network. host over a TCP/IP (or LU 6.2) "pipe" connection 555 to 

The network environment 550 is generally managed by acquire the SNA-specific information available from a vir- 

the NMS which, in the illustrative embodiment, is a UNIX tual telecommunication access method (VTAM) table 520 at 

workstation configured to execute a network management the host. The SNA View mainframe comp onent includes, a 

application. An example of such an application is the Cisco discovery monitor proC6S5 580 that queries vTAM wit h 
Works Blue Maps and Cisco Works Blue SNA View product 30 discovery rcguesLs tor retrievi ng the SNA-specific informa- 

set, available from Cisco Systems, Inc. The Cisco Works tion. The information may include (1) MAwJ>Ai' aaarcsses 

Blue product set provides a network operator with tools to of ihe host ana i^\J tor tne uma nost ana tnc ulUR router') 7 

draw a p ath of data transferred through the network env i- (ii) the PU name (or DLUR name for the PU),"(iii) itie FU 

ronmetit . 1 nat is, the product set provides a view of an SNA status, (iv) PU type, (iv)^a control point (CP) name of th e 
data session extending from the PU through the networ k 35 PU; (v) an identifier DiocK numper/identifaer numb er 

environment to ttie tiost. Using the product set, the operator (IDBLK/IDN UM) of the PU and (vi) RIF, if prese nt, 

may diagnosis prooiems by understanding the data path "^Ihe dli^covery monitor 580 loads the VTAM -retrieved 

through the network and isolating the problems to segments information onto a VTAM portion 632 (i.e, table) the 

in the network. The present inventi on is an extension to the repository. The VTAM table 632 may be organized as a PU 
conventional approach tor correiaiing sinMf intormation 40 table and a LU table, each of which is indexed by PU name. 

in a computer network utilizing this product set . The PU table may include information such a s PU name , PU 

Specifically, the invention compri ses a technique that status and PU type, whereas the LU table may include LU 

enables a network operator ot tH6 NIVIS 10 KMS'M j_U^t"s name, PU name and LU status information. The discovery 

session bas edimoiLanv. intormation that the use^^ monitor process populates the PU and LU tables, which are 
"e.g., SNA PU/LU name, IP address, nSSTa access control 45 thereafter accessed the VTAM protocol server 602. 
^AC)/service access point (SAP) address) and without The remaining protocol servers access information from 

requiring the operator to first determine the protocols used their respective tables which are organized according to the 

by the session. This allows the operator to quickly diagnose protocols. In the case of the DLSw protocol, for example, 

problems by gathering details about the affected session. As there is a DLSw circuit table 634 containing information, 
noted the illustrative embodiment of the present invention is 50 such as DLSw circuit IDs and the DLSw peer routers 

directed to SNA sessions carried over various protocols used establishing those circuits, known to the DLSw protocol 

in a computer network. However, it will be apparent to those server 604. This information is collected using conventional 

skilled in art that the invention may be applied to any simple network management protocol (SNMP) management 

situation where it is desirable to locate a resource used in information bases (MIBs) associated with each protocol in 
different environments. An example is that the present 55 accordance with various disco very/poller processes and then 

invention could be applied to voice sessions carried over populated according to the structure of the repository, 

various protocols. Examples of MIBs that may be advantageously used with 

nc 6 is a schematic block diagram of the NMS 600 the present, invention include a DLSw MIB disclosed in 

comprising a novel correlation engine 620 coupled to a Request for Comment (RFC) 2024, an IBM-6611-APPN- 
plurality of protocol servers. Each protocol server is con- 60 MIB disclosed in RFC 1593, an APPN MIB disclosed in 

figured to obtain protocol-related information pertaining to RFC 2455, a TN3270 MIB disclosed at <http:// 

the sessions utilizing its particular protocol. The protocol www.cisco.com/public/mibs/v2-vl/ClSCO- 

servers preferably include a VTAM protocol server 602, a TN3270SERVER-MIB-VISMLmy>, a DLUR MIB 

DLSw protocol server 604, a RSRB protocol server 606, a described in RFC 2232 and a RSRB MIB disclosed at 
TN3270 protocol server 608 and an APPN protocol server 65 <http://www,cisco.com/public/mibs/v2-vl /CISCO -RSRB- 

610. The servers 602-610 may be distributed across a MIB.my>, each of which is hereby incorporated by refer- 

plurality of platforms rather than resident on a single NMS. ence in its entirety. 
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[n the illustrative embodiment the protocol servers nizes PU names and MAC addresses, but not router or 

(VTAM, DLSw, APPN, RSRB and TN3270) preferably run DLUS names. Therefore the correlation engine 620 creates 

under a single application protocol server "daemon" 615 a filter 625 for the VTAM protocol server 602 that contains 

configured to access the repository, which is populated by a only the PU name ABC* and MAC address 0. Note that wild 

plurality of discovery/poller daemons. The daemons are 5 cards * are allowed on any fields which represent names, 

processes that execute in the background and perform work xhe protocol server searches its respective table and if it 

without user intervention. The discoverjVpoller daemons finds PUs meeting that name and address criteria, it responds 

^MXAp'.''" op^tmg system (e.g., UNIX) and utilize to the engine with a list of sessions in Step 710. If a pr^ocol 

SNMP to a^uire information needed to populate the various ^^^^^ ^.^^^ ^^^.^^^ ^^^^ ^^^^^ filter criteria 

protocol tables. Alter populating the respective tables with , • ' • r » ji ^ , 

• J • f . 1 , 10 are mcluded in the session hst regardless of the protocols 

he acquired mformaUon the protocol servers access the the sessions. Note that it is possible to explicitly 

tables to search on that .nforrnation. TTie protocol servers are ^^^^^ ^^at match one or more protocols or that do 

preferably rmplemented as object-onented C++ classes that ^ ^^^^ protocols, 

define certain APIs configured to retneve information, , . 

Tlie NMS forther includes a translation server process 645 , , According to the mventivc technique, the initial list of 

for translating service requests into session parameters for ^'^l^^^^ % ' P^J^°^°| ^^^^ ^!fif' 

use by the correlation engine 620. Th. service requests are ^^^^^"^ f ^ f'Z r'?'' P'^'"'"' 

issued by a network user (customer) concerning a session ^^^'^ ''f'f "^V^'u u^'^'^i- c'°' 

and includes any information that the user can provide about f^J'l;, '^VlT^"^- becomes the working list in Step 

the session. In the illustrative embodiment, the translation I^^' ^°f^ f^^^f ^ § f ^^/""^f"^ ^" 

server may be implemented as a web-based management ."^^ P^T^'r^^vp^ ^TJ.""' '^^^P^^^^ ' ^^'^^ 

tool comprising a web server process executing on the NMS (STATUS=ACnVE) is included it is possible that more than 

and configured to service hypertext markup language m'T^ "Z"^'' 

(H™L) requests received over the TCP/IP network (such as ^t'^"" ^ ff^^k ' ^"f"^ "^^^^.^^ 

tu^ iot/rn^7>i u^r^ ^ i.c^r/^^ „,«rVot , o„ subscqucnt scssion fists 660 retuHied by pFotocol scrvcf With 

the Internet). Here, a user (e.g., workstation) issues an ,r . ^ , . . ' ^ 

u-r*/fT • , , i:Ae u ^- the working list 650 in Step 716. 

HTML service request to the server 645 by sending a ^ ^ 

message to a uniform resource locator (URL) address of the Merging of a subsequent session list with the working 

NMS. The web server responds by providing an HTML page session list operates in the following manner. If the subse- 

to the user which inputs the requested information in HTML ^^^"t session list 660 includes information that matches 

format and forwards it to the server 645. The web server 30 information about a session in the working Hst 650, then the 

translates the request into a set of session parameters, sessions are considered the same and the session infor- 

examples of which include a PU name, MAC/SAP address mation from each protocol is combined into a single session, 

of the workstation, router name and DLUS name. The router subsequent session list information does not match the 

name may comprise a domain name system (DNS) name (or information pertaining to any working list session, then the 

IP address). subsequent session list information is added to the working 

no. 7 is a flowchart illustrating the sequence of steps ^^^^ ^ session, 

involved in the novel session list technique (process) of the I" general, each protocol acquires different information 
present invention. The process starts at step 700 and pro- . ^^out a given session; therefore, the inventive technique 

cecds to Step 702 where a user issues a service request, such further includes correlation of the information to identify 

as an HTML request, to the translation server of the NMS. 40 whether a session returned by the protocol servers is the 

In Step 704 the server translates the request into a list of all same as a session in the working list. For correlation 

sessions having, e.g., the following parameters: a PU name purposes, information maintained in the VTAM table 632 

of ABC*, a workstation MAC address of 0, a DLUS name includes LU name, PU name, source and destination MAC/ 

Y and passing through a router having a name Charlie. The SAP addresses, IDBLK/IDNUM, CP name and routing 

server 645 forwards these parameters to the correlation 45 information. Correlation with APPN and TN3270 sessions 

engine 620 which, in Step 706, creates a list of filtering data can be achieved using the PU name, MAC/SAP addresses, 

structures or "filters" 625 from the parameters. As used DLUR name, IDBLK/IDNUM and CP name. The DLSw 

herein, a filter pertains to any searching criteria that can be table information used for correlation may include MAC/ 

obtained about a session. In Step 708 the filter 625 is SAP addresses, while RSRB sessions may be correlated 

provided to a protocol server to search its portion of the 50 ^^^"8 routing information. 

repository (or its respective MIB) for information relevant to Referring again to the creation of filters, the correlation 

the request. engine may determine that DLSw recognizes MAC/SAP 

Specifically, the correlation engine 620 scans the param- addresses and router names, but not PU or DLUS names, 

eters and creates filters 625 for those protocol servers that it Therefore the correlation engine 620 creates a filter 625 for 

has determined can provide information relating to the 55 the DLSw protocol server 604 that contains only the MAC 

request. In this respect, the correlation engine functions as a address and router name. The DLSw server 604 thus 

"front-end" to the application protocol server 615. Since not searches its portion (table) 634 of the repository for sessions 

all of the filters apply to all of the protocols, the correlation having the MAC address 0 and passing through the router 

engine may pass a subset of the filter list to each protocol Charlie. If found, the protocol server 604 returns a session 

server. If a protocol server cannot handle the filter criteria, 60 list 660 having SNA sessions that meet the filter criteria, 

it is not called by the correlation engine. In the illustrative The correlation engine 620 then merges the two lists by 

embodiment, the VTAM protocol server is always passed a scanning the working list to determine whether there are 

filter list and is expected to return a list of sessions for each already session entries similar to the sessions provided by 

specified protocol because all SNA sessions are VTAM the DLSw protocol server. For example if only one session 

sessions whether or not they utilize another protocol. 65 in the DLSw list has a MAC/SAP address that matches a 

Thus based on the nature of the requested information, the session in the VTAM working list, then it can be assumed 

correlation engine may determine that, e.g., VTAM recog- that the two sessions are similar However if either list has 
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more than one session with the same MAC/SAP address, it PU names starting with ABC* and whose sessions traverse 

cannot be determined which of those sessions are similar so the router Charlie. Flags are set for each session returned by 

the DLSw sessions are added to the working list as new the VTAM protocol server thereby indicating the session is 

sessions. known to that server and that the session satisfies the ABC* 

In Step 718, the above process is repeated for each 5 name filter. Session flags are also set for each session 

protocol server; that is, the correlation engine determines ^^^^^/"^^^^^^"g.^hat the 

whether there is any filter that can be applied solely to a fff^r" L^^Z^TlT^r^^^^^^^^ 

, / -r • r J J. ... . 1 router name Charlie II Iter. Flags are turther asserted for those 

protocolserver and, if so, it is fonvarded to that protocol ^^S^ ^^^^^ ^^^^ ^^^^^ ^-^^ ^^^^^ 

server. Tlie protocol server, in turn, determines whether there ^^^^^^^^ ^^us indicating that the sessions are known to both 

are any sessions that meet the filter cntena and, if so, those lO ^^^^^^^^^ ^^at they pass both filter criteria, 

sessions arc merged or added as described ab^^^^^ Referring again to the previous example, the RSRB 

of the APPN protocol server 610, the APPN protocol rec- p^ot^col server 606 may be provided with a filter 625 that 

ogmzcs MAC addresses, router names and DLUS names. includes a router name parameter. The RSRB protocol server 

The correlation engine 620 thus creates a filter 625 for the searches its portion 636 of repository for all sessions match- 
server 610 based on the MAC address 0, router name Charlie 15 .^^ ^^^^^^ ^^^^ ^^^^ ^ ^^^^.^^ ^ ^^^^^^ ^ 

and DLUS name Y cntena. The APPN protocol server 610 correlation operations arc performed. The additional infor- 

then scans its portion 640 of the repository 630 to decide j^ation provided by the RSRB protocol server 606 may 

whether there are any sessions matching the fiUer criteria. j^clude RIF information that is merged into a matching 

As noted, the merging operation also comprises some session entry. The RIF information may be used for corrc- 

degree of correlation. For example, VTAM recognizes PU lation between the working list and the SNA-specific infor- 

names and associated extensions that identify the host 510 mation supplied by the VTAM table 520 over the pipe 555 

(VTAM) from which the PU names were obtained. When the when searching for a PU name. 

VTAM information is initially loaded onto the repository. Further to the previous example, the TN3270 protocol 

the PU names are qualified by the mainframe from which server 608 has knowledge of PU and router names; therefore 

they were obtained. APPN, on the other hand, only recog- a PU and router name filter 625 is provided to the server 608. 

nizes PU names and does not understand the associated xhe TN3270 protocol server searches its table 638 and if it 

extensions. APPN does, however, recognize an IDBLK/ finds sessions meeting the filter criteria, it responds to the 

IDNUM and CP name associated with the PU name. The engine with a list of SNA sessions that have a PU name of 

APPN data may be correlated with VTAM data based on PU aBC* and pass through the router Charlie. The sessions of 

name along with IDBLK/IDNUM or CP name. the list are similarly merged and correlated by the correlation 

Partial matching of the session list 660 generally indicates engine 620 to produce a single working list 650 of sessions, 

that the sessions are not identical; therefore an additional This completes the merger/correlation stage of the inventive 

multiple criteria matching operation is performed to ensure technique. 

that sessions are similar. If this operation does not confirm After invoking all protocol servers that support the 

the similarity of the sessions, then the new session is added requested filters, Step 720 ensures that the sessions matching 

to the list. For example, the VTAM protocol server returns the non-protocol filters are known by the requested protocol 

a session in the working list having a PU name of ABCl and servers. This stage of the technique addresses the problem 

a CP name XYZ. In addition, the APPN protocol server related to, e.g., a request for all PU names that start with 

returns a session with a PU name of ABCl and a CP name ABC* and that utilize a particular protocol for transport. For 

of DEF. It is apparent that the sessions are not the same and, this example, the particular protocol is the DLSw protocol 

as a result, the working list is expanded to include two and the non-protocol filter is the PU name filter. Since the 

sessions having the PU name ABCl. DLSw protocol server has no knowledge of PU names and 

In general whenever a protocol session list 660 is merged cannot handle the PU name filter, it is not called during the 
with the working list 650, both correlation and merging 45 first pass of protocol server invocation. Only the VTAM 

operations occur. In the case of correlation, a determination protocol server is invoked and it returns a list of sessions that 

is made whether a session returned by a server is already match the PU name filter. 

present on the working list based on any type of filtering According to the invention, a determination is then made 

criteria; if so, the session is merged into the working list. If as to which of the returned sessions are DLSw sessions. The 
the protocol server returns additional information about a 50 MAC/SAP addresses (if present) of the returned sessions are 

session in the working list and it is determined that the two passed to the DLSw protocol server for comparison with its 

sessions match, the additional information is added to the locally-stored MAC/SAP addresses of sessions using the 

working list session entry. For example, the APPN protocol DLSw protocol. A flag is then asserted for each matching 

server 610 may provide a DLUS name that was not previ- session, thereby indicating that both VTAM and DLSw 
ously associated with the matching working list session. As 55 protocols have knowledge of the session, 

sessions are merged in connection with this technique, more The next stage of the technique involves sorting of the 

information is provided for each session in the working list working list session entries based on whether the sessions 

650. match all of the filters (the highest order) and by PU name, 

Furthermore as each session froni a server is merged into if present (Step 722). Each session of the working list that 
the working list, a first flag may be asserted for each merged 60 matches all of the filter criteria (including the desired 

working list entry denoting the protocol that was merged protocols, if present) is flagged as matching the requested 

into the entry. In addition, a second flag may be asserted filters. The session that matches all of the fillers supplied to 

denoting an additional filter was matched within the session all of the protocol servers is first in the list. If there are 

entry. Assertion of the flags indicate which protocols have multiple sessions that match all of the filters, those sessions 
information about ("knowledge of) the session and which 65 are further sorted by PU name. 

filters were satisfied by the session returned by the protocol Thereafter, sessions are sorted by the highest number of 

server. Refer again to the example of the filter request for all partially matched filtering criteria (i.e., filters and protocols). 
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For example if the request is directed to sessions having PU only a MAC/SAP address, the session would be found but 

names starting with ABC*, an active state, a PU type 2.0 and the intent is to remove the requirement for the operator to 

that utilize the DLSw protocol, there may be sessions in the need to know what information to enter. The present inven- 

lisl that do not match all of these filters. That is, a session tion allows the operator to enter any and all of the informa- 

may have a PU name starting with ABC*, have a PU of the 5 tion it knows and the correlation engine responds by return - 

type 2.0 and use the DLSw protocol, but is inactive. This ing a list of sessions sorted by the number of matches, 

session thus matches three out of the four filters. Those Moreover, the inventive technique enables the conrelation 

sessions that match all of the filters appear higher in the list engine to choose a session from potentially many sessions as 

than the session matching three filters, which is followed by a correct s^sion for the filtering criteria, 

sessions that match two filters. While here has been shown and described an illusu-ative 

In Step 724 the resulting sorted sessions are returned to embodiment for identifying a session of a multi-protocol 
the user (via the web server 645) in a session table formal network without knowledge of the protocols used by the 
similar to that shown in Table I of FIG. 8. A column heading session, it is to be understood that various other adaptations 
is present in the table only if at least one session has data for modifications may be made within the spirit and scope 
that heading. For example, if no information is provided of the invention. In an alternative embodiment of the present 
about a DLUS name for any session, that column heading invention, one or more protocols may be specified as filler- 
does not appear in the table. Multiple sessions are listed in ^"^^"^ ^^'^ ^^^^^ ^ "^^^ session mforma- 
table format because the user may need to select a particular ^'^^^PL"' ^rlf o ''°"'/^^onl 
session. Accordingly, the user is provided a list of sessions ^ ^.^^"^ ^^^} f/^ "^""^"^ DLSw and RSRB 

. . u * J fiu • * J .u protocols. Here, the correlation engme need only generate 

that match the requested flltermg parameters and the user ^Uers for the DLSw and RSRB protocol servers, thereby 

selects the session that may assist in diagnosing the problem ,,3^1^^ ^ ^^^^ ^^^-^^^ ^^^^^ ^^^^ J, 

with the network. If the resultmg table comprises only one ^^^^^^ ^eed to be polled 

session, the information provided tothe user may include a ^^^^^^^ however, the DLSw protocol server has 

graphical depiction of that session. The process then ends in knowledge of PU names although the user is requesting 

Step 726. 25 information about a DLSw session. This aspect of the 

Advantageously, the invention provides an interface for a inventive technique requires that the VTAM protocol server 

network operator of a NMS to locate any managed session be queried to return all information that it has pertaining to 

in its network by entering whatever data it knows about the a particular PU name. The VTAM protocol server may 

session. As networks grow more complex with respect to the return, for example, MAC/SAP address information along 

number of protocols used, it becomes increasingly important 30 ^^^^ information pertaining to the PU name. As noted, 

for an operator that takes an initial call from a customer to the VTAM protocol server is queried and issued a filler for 

be able to gather as much data as possible regarding the ' requesi from a user because all of the sessions are SNA 

problem. The operator typically does not have knowledge • sessions. 

(apart from the information provided by a customer) of the Although the illustrative embodiment is directed to SNA 
protocol used by a particular session of a muUi-protocol 35 sessions propagating through various network 
network. Without the present invention, the operator typi- configurations, the invention may likewise apply to any 
c ally invokes a management application for each protocol to other type of protocol including voice/data/video- 
determine whether that application is "aware" of the session. encapsulation type protocols. For example, the applications 
The present invention provides a method for allowing the server daemon may include a *' Voice-over-IP" protocol 
application to do that work for the user. 40 server, a "Video-over-DLSw" protocol server and other 
By returning all sessions that match any filter criteria similarly characterized voice/data/video-encapsulated pro- 
insteadofjust those sessions that match all of the criteria, the tocols. Issues similar to that described in the illustrative 
inventive technique avoids issues created when the operator embodiment may arise because of the plurality of voice 
mistakenly enters conflicting information. For example, a connections over the network and the fact that a user may 
customer may call a service operator with a problem con- 45 which protocol is employed by the particular 
cerning a session and provide the operator with a PU name network session. Accordingly, the same inventive method - 
and MAC/SAP address. If the operator mistypes the MAC/ ology described herein would apply to these types of encap- 
SAP address but correctly enters the PU name and there are sulation sessions. 

no sessions that match the MAC/SAP address, a list may still The foregoing description has been directed to specific 

be returned with a session that matches the PU name. The 50 erabodimentsof this invention. It will be apparent, however, 

session is flagged as not matching the filter criteria since it that other variations and modifications may be made to the 

only matched one out of the two filters, but the operator is described embodiments, with the attainment of some or all 

returned a session and can confirm with the customer that the of their advantages. Therefore, it is the object of the 

address is correct. appended claims to cover all such variations and modifica- 

Continuing with the above example, it is desirable for the 55 ^ons as come within the true spirit and scope of the 

operator to enter both the PU name and the MAC/SAP inventiori. 

address because the operator should not have to know about What is claimed is: 

the protocols known to the NMS. For example it is possible 1. Amethod for identifying a data session flowing through 

the NMS does not have a way of obtaining any information entities of a multi-protocol network without requiring 

regarding VTAM sessions, but can obtain information about 60 knowledge of the protocols used by the session, the method 

APPN, DLSw, RSRB and TN3270 sessions. If the customer comprising the steps of: 

session only uses the DLSw protocol to encapsulate a SNA creating one or more filters at a conelation engine of a 

(VTAM) session, the APPN, RSRB and TN3270 protocols network management station (NMS) for use by one or 

have no knowledge of that session. If a user only provides more protocol servers of the NMS; 

the PU name to the correlation engine, the engine is unable 65 obtaining protocol -related information pertaining to the 

to locate the session since the DLSw protocol server does session at the protocol servers, the protocol-related 

not understand PU names. If the operator correctly enters information matching at least one of the filters; 
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merging the obtained protocol-related information into a 

list of session entries; 
sorting the session entries of the merged list according to 

a number of matching filters; and 
providing a list of sorted session entries to the user. 

2. The method of claim 1 further comprising the step of 
translating a service request issued from a user of the 
network to session parameters. 

3. The method of claim 2 wherein the step of creating 
comprises the step of creating the filters from the translated 
session parameters. 

4. The method of claim 1 wherein the step of obtaining 
comprises the steps of; 

organizing a NMS repository as a plurality of tables, each 
table containing protocol-related information associ- 
ated with a protocol server; and 

searching the NMS repository for the protocol-related 
information pertaining to the session. 

5. The method of claim 4 wherein the step of obtaining 20 
further comprises the step of designating an initial list of 
sessions returned by a protocol server as a working list. 

6. The method of claim 5 wherein the step of merging 
comprises the step of merging subsequent session lists with 
the working list. 

7. The method of claim 6 wherein the step of merging 
further comprises the steps of: 

combining a session from the subsequent list into a single 
session of the working list if the protocol-related infor- 
mation about the subsequent list session matches the 
protocol -related information about the working list 
session; and 

adding the session from the subsequent list to the sessions 
of the working list if the protocol- related information 
about the subsequent list session does not match the 
protocol-related information pertaining to any of the 
working list sessions. 

8. The method of claim 7 wherein the step of merging 
further comprises the step of asserting predetermined flags 
to indicate which protocols have information about the 
session and which filters are satisfied by the session. 

9. The method of claim 8 wherein the step of sorting 
comprises the step of sorting the sessions of the working list 
such that the session that matches all of the filters supplied 

to all of the protocol servers is first in the list. ^5 

10. The method of claim 9 wherein the step of sorting 
further comprises, if multiple sessions match all of the 
filters, sorting the sessions of the working list by physical 
unit (PU) name. 

11. The method of claim 10 wherein the step of sorting ^0 
further comprises the step of sorting any remaining sessions 

of the working list by highest number of partially matched 
filtering criteria. 

12. Apparatus for identifying a data session flowing 
through entities of a multi-protocol network without requir- 
ing knowledge of the protocols used by the session, the 
apparatus comprising: 

a translation server of a network management station 
(NMS) coupled to the network, the translation server 
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configured to translate a service request issued from a 
user of the network to session parameters; 

a correlation engine coupled to the translation server and 
adapted to create one or more filters from the session 
parameters; and 

an application protocol server coupled to the correlation 
engine, the application protocol server comprising a 
plurality of protocol servers for receiving the filters 
from the correlation engine and for obtaining protocol- 
related information responsive to the received filters. 

13. The apparatus of claim 12 further comprising a 
repository for storing the protocol-related information 
obtained by the protocol servers. 

14. The apparatus of claim 13 wherein the repository 
comprises a plurality of table structures, each containing the 
protocol-related information associated with a protocol 
server 

15. The apparatus of claim 14 wherein the protocol 
servers include a virtual telecommunication access method 
(VTAM) protocol server, 

16. The apparatus of claim 15 wherein the protocol 
servers further include one of a data link switching (DLSw) 
protocol server, a remote source route bridging (RSRB) 
protocol server, a telnet protocol server and an advanced 
peer to peer networking (APPN) protocol server. 

17. The apparatus of claim 15 wherein the protocol 
servers further include a data link switching (DLSW) pro- 
tocol server, a remote source route bridging (RSRB) proto- 
col server, a telnet protocol server and an advanced peer to 
peer networking (APPN) protocol server. 

18. A computer readable medium containing executable 
program instructions for identifying a data session flowing 
through entities of a multi-protocol network without requir- 
ing knowledge of the protocols used by the session, the 
executable program instructions comprising the program 
instructions for: 

creating one or more filters at a correlation engine of a 
network management station (NMS) for use by one or 
more protocol servers of the NMS; 

obtaining protocol-related information pertaining to the 
session at the protocol servers, the protocol-related 
information matching at least one of the filters; 

merging the obtained protocol-related information into a 
list of session entries; 

sorting the session entries of the merged list according to 
a number of matching filters; and 

providing a list of sorted session entries to the user. 

19. The computer readable medium of claim 18 further 
comprising program instructions for translating a service 
request issued from a user of the network to session param- 
eters. 

20. The computer readable medium of claim 19 wherein 
the program instructions for creating comprises program 
instructions for creating the filters from the translated ses- 
sion parameters. 



04/29/2004, EAST Version: 1.4.1 



